Email is a popular form of electronic communication between individuals and is widely used for intra- and inter- organizational business communication. Email, however, has a number of longstanding privacy and security shortcomings, which may potentially be exploited on mass scale. Despite existing security limitations, email communication is attractive because of its low cost and very large user base worldwide.
Email uses a store-and-forward messaging system from sender to recipient that is difficult to control or even trace. Internet security technologies, such as Secure Sockets Layer (SSL), that can be applied well to secure point to point transactions, such as used for credit card transactions, or other client-server communications, are not suitable for multi-hop communications, or to secure email communications that involve store and forward messaging from a sender to a recipient across different network domains.
There are a number of known certificate based approaches for securing email and other electronic communications using public-key infrastructure (PKI) and public-key/private-key pairs (public-private-key pairs), but they tend to be employed in limited circumstances, such as within a private data network, or to secure communications between subscribers and their own service provider in a public network. In the latter case the channel is secure, but the information transmitted by the channel is not necessarily encrypted. Typically, known systems require registration and generation of a public-key certificate with a public-private-key pair, which is issued to a subscriber by a trusted certificate authority. A record of the certificate and its association with a particular subscriber is kept in a secure server by the trusted authority, and public-keys are made available on public-key servers.
One of the most widespread methods is based on X.509 certificates and PKI (Public-Key Infrastructure). This type of system is described, for example, in U.S. Pat. No. 6,061,448. However, as described below, digital certificates are typically centrally managed by Certificate Authorities (CA) and implementation of PKI systems is complex and costly. For Enterprises, trying to create, distribute and maintain digital certificates for a large number of users may not be practical.
Furthermore, what is classified as secure email may depend on security requirements, and secure email may refer to one or more of:                message confidentiality (only the sender and recipient are privy to die message),        message integrity (the message was not tampered with), and        authentication (the sender and recipient have verified identities).        
For example, considering these three aspects or “classifications” of encrypted email, in some instances, when message confidentiality only is provided, an email may not be considered secure because it does not authenticate the sender and does not provide message integrity. Digitally signed email alone, for example, may not be considered secure email because, even though it authenticates the sender and provides message integrity, digitally signed email does not provide message confidentiality and does not authenticate the recipient Trust is important to any business relationship, and unless an email is digitally signed, recipients cannot trust the “From:” field in the email message. Depending on the context and content of a communication, to be qualified as “secure email” all three of message confidentiality, message integrity, and authentication may be required.
A procedure based on X.509 certificates requires that senders and recipients obtain certificates from a trusted certificate authority. A user wanting to receive secure email has to actively address a Certificate Authority, and prove his identity to the Certificate Authority, which typically involves costly and time-consuming procedures—e.g, physical travel, identification by postal services, to obtain a certificate and public-private-key pair. The effort involved with establishing the identity of a person or legal entity to obtain a certificate, may not be considered necessary or desirable in many applications of email communication, and may deter many potential users. Furthermore, unless sender and recipient both belong to an organization with a common PKI infrastructure, interoperability of different systems may be an issue, and many steps have to be performed to enable potential senders to and recipients to exchange encrypted email
For example, a user typically has to perform the following steps to be able to receive secured, i.e. encrypted email:                Contact a Certificate Authority to request a certificate and a public/private-key pair.        Authenticate himself with the Certificate Authority—often, the Certificate Authority requires authentication in person to ensure that the certificate is received by the natural or legal person it is issued for.        The Certificate Authority issues a certificate for the requestor and signs it with its own private-key. Thus, using the public-key of the Certificate Authority, the integrity of the issued certificate can be proven.        The Certificate Authority also generates a public/private-key pair and associates it with the certificate of the requestor.        The private-key is encoded with a password entered by the requestor.        Certificate, private and public-key are given to the requestor, The private-key is deleted at the Certificate Authority.        Certificate and public-key are stored on one or several secure servers accessible to the public, or accessible only to a desired user group.        
When another user (sender) wants to send a secure email to the above user (recipient) for the first time, the sender must obtain the recipients public-key, for example by one of the following steps:                Find a link to the recipient's public-key associated with his email. Usually, this link is distributed by the recipient to potential communication partners, e.g. in a mail signature. Alternatively, the public-key can be looked up on a PGP key server, as for example described in U.S. Pat. No. 6,836,765. However, since PGP servers synchronize user level entries, this type of system is not believed to scale for billions of secure email users        As an alternative to above, an LDAP (Light Weight Directory Accessible Platform) central server could be used to store users' public certificates and be available to senders who want to send secure e-mail to the recipients, as presented in a paper “Using LDAP Directories for Management of PKI Processes” published in Proceedings of Public-key Infrastructure: First European PKI Workshop: Research and Applications, EuroPKI 2004, Volume 3093, Pages 126-134, June 2004. However, this method is typically used in intranet situation due to security weakness in LDAP server, as presented in a paper “Deficiencies In LDAP When Used To Support Public-key Infrastructure” published in Communications of the ACM, Volume 46, Issue 3, Pages 99-104, March 2003. A distributed database system as introduced in U.S. Pat. No. 7,123,722 could also be used to store user's public certificates and be available to senders who want to send secure e-mail to the recipients. This distributed database system has the similar security problem as a LDAP server.        When the sender has determined the recipient's public-key, the user stores the recipient's public-key in a file, and imports the recipient's public-key into the sender's certificate store.        
The certificate store may be a certificate store provided by the operating system or an application specific certificate store provided by a dedicated encryption/decryption application or by the mail client application.
The sender may then encrypt the mail with the recipient's public-key in one of the following ways for sending the email to the recipient:                Write the mail body in a file and encrypt this file along with other attachments in an application unrelated to the mail client. Then attach the encrypted file produced by this application to a mail from sender to recipient.        Manually trigger a function of the mail client to encrypt the mail to the recipient using the recipient's public-key.        On sending, the mail client automatically checks the certificate store whether a public-key for the mail recipient is available. If yes, the mail client either offers a choice to the sender—encrypt mail to recipient or not—or encrypts the mail to recipient automatically.        
Thus although the use of X.509 certificates and PKI infrastructure can provide for message confidentiality, message integrity, and authentication, ease of use and ease of deployment in email security application remain a challenge. Notably, even after years of development since PKI technology was introduced in the 1980 secure email based on X.509 certificates and PKI is still not a mainstream application today—either within corporations, or particularly among different corporations that entertain business-to-business (B2B) relationships where interoperability of different systems remains an issue.
Consequently, at least for the above reasons, the adoption rate for inter-organizational secure email has been slow, and the majority of emails are still sent in the clear, leaving email subject to eavesdropping, and making it more difficult to fight spam.
Other approaches have attempted to provide alternatives to the use of certificates. For example, a public-key cryptosystem with roaming user capability within a network that allows secure transmission of e-mails between users of the system is described in U.S. Pat. Nos. 6,154,543 and 6,292,895. A client machine generates and stores an encrypted private-key on a central encryption server. A user may then access the encrypted private-key from any client machine located on the network and decrypt it using a pass-phrase, thus giving the user roaming capability, The private-key may then be used to receive and decrypt any email encrypted using the user's public-key. A user can generate a digital message, encrypt it with a client recipient's public-key, and transmit it to the recipient's email server from any client machine on the network. This approach has the limitations that because when a user needs to read an e-mail, he has to log on to the central encryption server to get bis private-key, and thus this approach to secure email system has limitations with respect to scaling for billions of secure email users.
Another technique known as Identity Base Encryption (IBE) scheme was introduced in U.S. Pat. Nos. 6,886,096 and 7,003,117 to simplify the complicated process of dealing with certificates. IBE is a public-key cryptosystem where any string is a valid public-key. In particular, email addresses and dates can be public-keys. A trusted third party, called the Private-key Generator (PKG), generates the corresponding private-keys. The PKG publishes a “master” public-key, and keep the corresponding master private-key in a secret store. Given the master public-key, any party can compute a public-key corresponding to a user by combining the master public-key with the identity value. To obtain a corresponding private-key, the party authorized to use the user's public-key contacts the PKG, which uses the master private-key to generate the private-key for the party. As a result, parties may encrypt messages with no prior distribution of public-keys between individual participants. This is useful in cases where pre-distribution of public and private-keys is inconvenient due to technical restraints. This approach is not entirely satisfactory because the PKG must operate in a highly trusted manner, as it is capable of generating any user's private-key and may therefore decrypt messages without authorization.
Thus, although there are known systems and methods providing message confidentiality, message integrity and authentication for secure email, known systems have limitations or constraints to more widespread adoption, and/or are not readily scalable for large numbers of users. Systems that provide a satisfactory level of security may be seen as onerous or inconvenient for typical individual email users, and may be considered more complex than a typical user needs for many applications, or for inter-organizational communications.
Consequently, there is a need for public-private-key secure systems and methods for facilitating electronic communications such as email for parties communicating over a public data network, particularly when communications are not controlled by a single network operator or entity.